AWS Resilience Hubを触ってみました。

こんにちは、コンソル部のソウヌです。今回はAWS Resilience Hubを実際に触ってみました。

#AWS

#AWS Resilience Hub

NuNu

2022.05.18

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

初めに

AWS Resilience Hubのコンソルに接続します。まだ日本語の支援はしてないので全部英語になっていますね。AWS Resilience Hubを使用する前に対象になるリソースをCloudFormationで作成しました。

今回、対象になるアプリケーションの構成です。

シングルAZの上にPublic SubnetとPrivate Subnetが立てています。Public Subnetにはアプリケーションが起動する1つのEC2インスタンスとNat Gatewayが立ててあり、Private Subnetには1つのRDSインスタンスが立てている構成です。それではAWS Resilience Hubを使って復旧性を確認してみます。

アプリケーション追加

アプリケーションを追加するための四つのステップがあります。

1. Discover application structure

「Add application」ボタンをクリックして対象のアプリケーションを指定する画面に入ります。事前に作成したCloudformationスタックを指定します。今回は一つのスタックでリソースを作成しましたが、各リソース別のスタックがある場合、最大5つのスタックを指定することが可能です。

定期評価を行うScheduled assessmentオプションがあります。このオプションについて日間隔で評価を行うと説明していますが、詳細の内容は確認できませんでした。今回はテストなので一応無効化にします。

2. Identify resources

選択したスタックで評価対象になるリソース識別します。基本、評価対象でInclude状態ですが、Include resource, Exclude resource ボタンで評価する対象リソースを指定することが可能です。

3. Select policy

Select policy ステップではリソースに適用するポリシーを設定します。作成されているポリシーがあればそれを使っても大丈夫ですし新しいポリシーを作成してもいいです。私は「Create resiliency policy」ボタンを押して新しいポリシーを作成します。

DRや可用性などの知識がないと想定して、AWSから提供しているポリシーで作成します。Critical Application Tierポリシーを選択しました。

作成が完了できたら、Select policy画面に戻って作成したポリシーを設定して次のステップに行きます。

4. Review and publish

ここでは設定した内容を確認します。間違ったところがなかったら「Publish」ボタンを押してアプリケーションの追加を完了します。

アプリケーション評価

正常的にアプリケーションが追加されたらアプリケーションの評価ができます。Workflowの「Run new resiliency assessment」で新しい評価を実行します。

評価が終わると、その結果を簡単に確認できます。私は「ポリシー違反」結果が出ました。評価を行ったアプリケーションのRTO・RPOが設定したポリシーのRTO・RPOを満たすことができなかったという意味です。具体的な内容を確認するためレポートをクリックします。

結果レポート確認

結果レポートを確認します。レポート画面では簡略したレポートの結果と評価各項目の詳細な結果を確認できます。そして復旧性・運用上に関するAWS Resilience Hubの推薦も確認することが可能です。

まず、評価された項目の簡略な結果を確認します。

ECインスタンスのようなハードウェア側の問題が発生した状況を意味する「(Cloude)Infrastructure」のRTOの予測は１時間40分でポリシーで目標とした1時間より40分長いです。そして一つ以上のAZが使用できない状況を意味する「(Cloude)Availability Zone」は復旧不可能で予測されていますので「ポリシー違反」結果になりました。

次は各項目に関する詳細なことも確認します。Infrastructureに問題が発生するとdatabaseappcommponent(RDS)のRTOが1時間40分で予測されています。

「Availability Zone」にはdatabaseappcommponentとnetworkingappcomponentにポリシー違反があります。名前をクリックして詳細な情報を確認できます。そして予測した理由も確認できます。

networkingappcomponentの場合、NAT Gatewayが1つしか存在しないので復旧不可能（unrecoverable）に予測されました。そして、databaseappcommponentのRTO１時間40分の根拠はRDSバックアップから復旧されるまでの予想時間のことを確認できました。

推奨する復旧力事項

ポリシーを満たせる推奨事項を確認します。AWS Resilience Hubは3つの最適化方法を推薦しています。AZ中断の間、一番低いRTO・RPOが達成可能な推奨、コストを考慮した推奨、最小限の変更推奨です。

RDS に関して、シングルAZ→マルチAZへの変更を推奨しています。マルチAZに変更すると、各1時間40分、2分、2分の現在のRTOが5分、０、０に大幅に改善できますよね。評価したアプリケーションが単純な構成をしているのでAWS Resilience Hubが全部同じ最適化方法を推薦していると思います。

しかし、少し変なところがありました。「Estimated cost」は現在と変更後のコストを比較した項目です。Resilience Hubが構成を変更しても増えるコストが０だと話していますが、マルチAZ構成はPrimary 1, Standby 1 2台のDBインスタンスが必要になるので、1台のシングルAZ構成よりコストが高いはずです。推奨を適用する前にユーザー側でしっかり確認した方が良さそうです。

推奨する運用事項

運用上に必要なアラーム、SOP(Standard Operating Procedures)、AWS Fault Injection Simulatorを利用する故障注入実験ができるCloudFormationテンプレートを作成することが可能です。作成されたテンプレートは自動的にS3バケットに保存され、そのまま使えます。